Skip to content

ci: use release-please manifest prerelease config#877

Merged
bokelley merged 1 commit into
mainfrom
bokelley/release-please-beta-prerelease-mode
May 26, 2026
Merged

ci: use release-please manifest prerelease config#877
bokelley merged 1 commit into
mainfrom
bokelley/release-please-beta-prerelease-mode

Conversation

@bokelley
Copy link
Copy Markdown
Contributor

Summary

  • Switch Release Please to manifest mode so release-please-config.json is honored.
  • Keep the existing Python release strategy through manifest config, including versioning: prerelease.
  • Document beta-line behavior so beta releases increment beta.N instead of bumping the base minor version.

Why

The workflow passed release-type: python directly to the action. In that mode, Release Please does not use the advanced manifest configuration, so the beta prerelease strategy was not reliably driving release PR versions.

Validation

  • python3 -c 'import json; json.load(open("release-please-config.json")); json.load(open(".release-please-manifest.json"))'
  • ruby -e 'require "yaml"; YAML.load_file(".github/workflows/release-please.yml")'
  • git diff --check
  • npx release-please debug-config --repo-url adcontextprotocol/adcp-client-python --target-branch main --local --local-path . confirmed manifest config parses with versioning: prerelease and current version 6.3.0-beta.4.

Copy link
Copy Markdown

@aao-ipr-bot aao-ipr-bot Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Follow-ups noted below. Manifest mode is the right shape — the existing release-please-config.json already declares versioning: prerelease + prerelease-type: beta, and release-type: python as an action input was bypassing it entirely.

Things I checked

  • release-please-action@v5 invocation: with config-file + manifest-file and no release-type, the action takes the Manifest.fromManifest path and honors the config file. Setting release-type would have flipped it back to Manifest.fromConfig, which ignores the config file — that was the bug.
  • Downstream plumbing: steps.release.outputs.prs_created and the release-please--branches--main branch name are populated by release-please core, not the input mode. The Normalize release PR pyproject prerelease version step still gates and runs identically.
  • Bump math at 6.3.0-beta.4: feat: and fix: both route through bumpPrerelease("beta.4")6.3.0-beta.5. Matches the docs.
  • release-please-config.json and .release-please-manifest.json are syntactically valid and reachable (PR's debug-config evidence).

Follow-ups (non-blocking — file as issues)

  • feat!: behavior is undocumented and contradicts the new copy. RELEASING.md:187 says "keep the base version fixed and increment only the beta counter." Tracing PrereleaseMajorVersionUpdate.bump for 6.3.0-beta.4 (minor=3, so the patch === 0 && minor === 0 guard is false): a breaking change exits the beta line and produces plain 7.0.0, dropping the prerelease label entirely. Narrow the claim to non-breaking commits and add a one-liner on the breaking-change escape hatch.
  • No documented path from 6.3.0-beta.N to 6.3.0 stable. With versioning: prerelease the counter only increments. Graduation needs a manual Release-As: 6.3.0 footer (or a manifest edit). This will be the next support question — worth a 3-line "Graduating a beta" subsection.
  • bump-minor-pre-major: true / bump-patch-for-minor-pre-major: false in release-please-config.json are inert at major=6. Pre-existing, not introduced here, but they imply they're shaping current behavior. Worth deleting in a sweep.
  • Validation evidence covers parsing, not behavior. debug-config confirms the config is reachable; it doesn't simulate a feat: producing beta.5. A release-pr --dry-run against a synthetic commit would be stronger. Notable, because the very next release PR is the actual smoke test.

Minor nits (non-blocking)

  1. PYPI_SETUP.md:78-80 attributes the behavior to "manifest-mode config" — the actual cause is versioning: prerelease. Implementation detail vs. user-facing rule. Optional reword.
  2. PYPI_SETUP.md:77 still reads feat!: → major bump unconditionally. With the new bullet directly underneath, the two lines now have a subtle inconsistency on the beta line. Same fix as the RELEASING.md follow-up.

Approving on the strength of the mechanical change being correct and the downstream pipeline being undisturbed. The doc tightening can land in a follow-up.

@bokelley bokelley merged commit 8f93226 into main May 26, 2026
25 checks passed
@bokelley bokelley deleted the bokelley/release-please-beta-prerelease-mode branch May 26, 2026 16:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant